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Privacy Management of Personal Data 

Field of the Invention 

The present invention relates to privacy management of personal data. 

As used herein, the term "personal data" is intended to include data such as identity data 
and profile data (for example, preference data and financial data) of a party to which the 
data relates, whether that party is a natural or legal party. Furthermore, references to the 
"owner" of the personal data means the party responsible for its disclosure, whether the 
party is the subject of the data or a proxy for that party. 

Background of the Invention 

Digital identities and profiles of parties are becoming more and more relevant for enabling 
Internet transactions and interactions among citizens, service providers, enterprises and 
government institutions. For example, in an e-commerce scenario, a person initially 
provides their digital identity and profile information to an e-commerce site in order to 
access their services. After the user logs in and interacts with these services: it might 
happen that interaction with other web sites or organisations is needed to carry out a 
service. The user might be conscious of this or this might take place behind the scene, for 
example due to fact that the e-commerce site interacts with partners and suppliers. The e- 
commerce sites may or may not have prior agreements with these third parties or may or 
may not belong to the same web of trust. 

In general users have little understanding or knowledge of the privacy laws and legislation 
that regulate the management of their information. The privacy and data protection laws 
that regulate this area are hard to enforce or monitor, especially when private information is 
spread across organisations and national' boundaries. People perceive and address the 
related security and privacy issues in different ways, ranging from completely ignoring 
them (and indiscriminately disclosing their personal data), to being so concerned as to 
refrain from using any Internet applications. It is also frequently the case that users do not 
bother to read long lists of terms and conditions concerning privacy and confidentiality 



r rrr ^^^^^^ 

are often asiced to gran, authority l0 web ^ , 0 ^ 

chooses fl» eaaest way forward ,o obtaining the service they wan,. 

U«e has been done so far to a„ow me exphci, management and enforcement of privacy 
po ccs by d,rec„y invoMng users (or enfifies acfing on their behaH) espcoia y in 
context of mu,fipar<y taerac „ ons .. ^ _ a ^ rf J ^ J 

^on, eapeciaUy after „ s ^ disCosnre. m addnion, tMrd par,ie S ^ 
.0 ^gates, e-cornmerce shea or en,erpHses) have ,ac k ofcon.ro, over ,he confident., 

et::::, T maseonbe ™ e " 

external entities, dunng transactions or interactions. 
P ^™«o ta 

force ana,ysi, However, for aach so.uhon ,o succeed, tbey need ,o simphfy ul 

d*a „ managed m an account way. !f peop.e are no, wining ,o be invo.ved in the 

o .*» beha.f and eonid provide peop,e with eaay-fo-nae ,oo ls ,o monitor and xeep 2 
situation under control. P 

Mechanisms such as proposed by W3C a„ow use. to define simpie privacy pofieies bu, 
- ts omy meaning*, f or ^ p J >»< 

r: r ces d «-^«-w3cpr P os: 

Recommendation - 2002) 

So.utions based on federated identity managemen, have a,so been indented (such as 

m .,bepa rt of te ,ede,ubsandbeeom P ha J1 ,w 1 mpredefi„cdp nV acyplL Z 
approach Um its scanty and flexibihty of me aUowed interacnons and lacnonT 



3 

A more fine-grained control over the privacy of personal data has been described in the 
papers: 

- G. karjoth, M. Hunter - A Privacy Policy Model for Enterprises, IBM Research, 
Zurich - 15 th IEEE Computer Foundations Workshop - June 2002 
G. karjoth, M. Schunter, M. Waidner - Platform for Enterprise Privacy Practices: 
Privacy-enabled Management of Customer Data - 2nd Workshop on Privacy 
Enhancing Technologies, Lecture Notes in Computer Science, Springer Verlang - 
2002 

In the first of these papers the authors define a privacy control language that includes user 
consent, obligations and distributed administration. In the second paper, the authors 
describe a platform for enterprise privacy practices (E-P3P) and introduce the "sticky 
policy" paradigm and mechanisms for enterprise privacy enforcement. Sticky policies are 
policies that are strictly associated with a user's data and drive access control decisions and 
privacy enforcement. The papers do not, however, describe how the strong associations 
between policies and confidential data are enforced, especially across enterprise 
boundaries. Users still need to trust the enterprise when disclosing their data. Leakage of 
personal and confidential information might happen, despite data protection laws and 
privacy policies, because of lack of security, dishonesty of some of the involved 
intermediaries and the complexity of the overall systems. 

Furthermore, many of the current privacy mechanisms introduce an overhead in terms of 
usage of digital certificates at the user site (where data is encrypted) and complexity when 
dealing with dynamic metadata (policies) associated with the encrypted data 

It is an object of the present invention to provide an improved way of effecting privacy 

management for personal data. 

* 

The present invention is in part based on the appreciation that Identifier-Based Encryption 
(IBE) has certain properties than can be adapted for use in privacy management. 

Identifier-Based Encryption (IBE) is an emerging cryptographic schema. In this schema 
(see Figure 1 of the accompanying drawings), a data provider 1 0 encrypts payload data 1 3 



using an enaction key string 14 and public data 1 5 provided by a trusted authority^- the 

dataprovMenOthenprovidesfteeneryptedpayloadda^toareeipientHwhodecryptsi, 
usmg a decryption key 16 provided by the trust authority together with the latter's public 
data. The trusted authority's public data is derived by the authority using private data 17 
5 and a one-way function 1 8. Important features of the BE schema are that any kind of suing 
(mcludmg a name, a role, etc.) can be used as an encryption key suing 14, and that the 
generation of the decryption key 1 6 is effected by the trust authority (process 19) using the 
encryphon key string 1 4 and its private dam . 7, enabling the generation of the decrjption 
key 16 to be postponed until needed for decryption. Beeause the encryption key string 
10 frequently contains data identifying the intended recipient (for example, by a required 
characteristic), the encryption key string is also known as the identifier string. 

A number of IBE algorithms are known, one of which is the "Quadratic Residuosity" (QR) 

memoddescribedmmepapert-AnldentityBasedEncoptionSchemebasedon^adratic 
15 Residues". C. Cocks Communications-Electronics Security Group (CESG) UK 

http://www cesg gov „k/technoWid-p kc/menintrir.n p,1_f - 2001. A briefdescription of 
this form of IBE is given below. 

IntheQRmethod,thetrustauthorityspublicdata 15 comprises a value N that is a product 
20 of two random prime numbers p and q, where the values of p and q are the private data 1 7 
of the tros, authority 12. The values of p and q should ideafiy be in the range of 2 5 » and 
2- andshouldbomsatisfymeequafion: p, „. 3 mod 4. However, pattdqmus.no. have 
me same value. Also provided is a hash function # which when applied .cashing returns 
a value in the range 0 to N-l . 
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Each bit m of the user's payload data 13 is then encrypted as follows: 
- The data provider 10 generates random numbers K (where , + is an integer in the 
range [0, 2 N ]) until a value of K i s found that satisfies the equation Jacobi(U,N)=m, 
where m has a value of -1 or 1 depending on whether the corresponding bit of the 
user's data is 0 or 1 respectively. (As is well known, thcjacobi function is such that 
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-2 =i 



where x =#mo&N the jacobi (#, N) = -1 if x does not exist, and = 1 if x does 
exist). The data provider 10 then computes the value: 

s+ = {U+#{encryption_keystring)lt+)moAN 
where s+ corresponds to the encrypted value of the bit m concerned. 

- Since #(encryption_keystring) may be non-square, the data provider additionally 
generates additional random numbers t_ (integers in the range [0, 2 N )) until one is 
found that satisfies the equation Jacobi(t_, N)= m . The data provider 10 then 
computes the value: 

s- = (t--#(encryption_keystring)/t_)modN 
as the encrypted value of the bit m concerned. 

The encrypted values s+ and s. for each bit m of the user's data are then made available to 
the intended recipient 1 1 , for example via e-mail or by being placed in a electronic public 
area; the identity of the trust authority 12 and the encryption key string 14 will generally 
also be made available in the same way. 

The encryption key string 14 is passed to the trust authority 12 by any suitable means; for 
example, the recipient 1 1 may pass it to the trust authority or some other route is used - 
indeed, the trust authority may have initially provided the encryption key string. The trust 
authority 12 determines the associated private key B by solving the equation : 

B 2 = #(encryption_keystring)modN ("positive" solution) 

If a value of B does not exist, then there is a value of B that is satisfied by the equation: 

B 2 m -#(encryption_keystring)modN ("negative" solution) 

As N is a product of two prime numbers p, q it would be extremely difficult for any one to 
calculate the decryption key B with only knowledge of the encryption key string and N. 
However, as the trust authority 12 has knowledge of p and q (i.e. two prime numbers) it is 
relatively straightforward for the trust authority 1 2 to calculate B . 
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Any change to the enaction key string 1 4 will result in a decryption key 1 6 that will not 
decryptthepayloadd^^^ 

encryption key string before supplying it to the trust authority 12. 

The trust authority 12 sends the decryption key to the data recipient 1 1 along with an 
indication of whether this is the "positive" or "negative" solution for B. 

If the "positive" solution for the decryption key has been provided, the recipient 1 1 can 
now recover each bit m of the payload data 13 using: 
m =jacobi(s++2B,N) 

If the ■'negative" solution for the decryption key B has been provided, the recipient 11 
recovers each bit m using: 

m =jacobi(s_+2B,N) - 

15 Whilst in the foregoing example, the encryption key stringhas been used directly in the QR 
BE algorithm, i, is also possible to use in the encryption process a derivative of the 
enoryptionkey string, ttuaderivativebemg formed, for example, byusmgapredetemrined 
hash function. In mis case, the entity generating the decryption key can still simply be 

20 ,„ form the derivative of the encryption key string (in fact, this is equivalent ,o using a 
vanan, of stated the QR BE algorithm in which the predetermined function is applied to 
theencrypnonkeystiingwhereverfte latter appear,). Where the decryption-key generating 
ennty does not need to access the contents of the original encryption key string then i, 
need only be provided with the derivative of the encryption key suing used during the 
25 encryptron process. In the following description, where the term "encryption key is used 

thtsisimendedtomfertottefotmofmeencryptionkeysmngusedmrnes^tedversionof 
IBE algonthm concerned whether tins is the unprocessed encryption key string or a 
denvahve formed by subjecting the encryption key suing to predetermined processing. 

30 Other BE algorithms are known such as the use of Weil or Tate pairings - see for 
example: D. Boneh, M. Franklin - "Identity-based Encryption from the Wei! Pairing" in 
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Advances in Cryptology - CRYPTO 2001, LNCS 2139, pp. 213-229, Springer- Verlag, 
2001 . BE algorithms based on the Weil or Tate pairings are usually described in terms of 
there being an IBE encryption key that is derived in a predetermined manner from an 
encryption key string (though it would be possible to re-state the algorithms such that the 
5 encryption key string formed the encryption key to be plugged into the algorithm). 

Summary of the Invention 

hi general terms, the present invention involves using a privacy policy as an IBE 
1 0 encryption key string for the personal data to which it relates thereby tightly associating 
the policy and data and requiring the policy to be disclosed, unaltered, to the trust authority 
who has the ability to provide the decryption key. The trust authority then has the 
responsibility of ensuring that the policy conditions have been satisfied before it releases 
the decryption key. No secret needs to be generated and exchanged between users and the 
15 receivers of confidential information. 

More particularly, according to one aspect of the present invention, there is provided a 
privacy management method, comprising: 

first operations, effected by an owner of personal data, comprising encrypting the personal 
20 data and providing the encrypted data to a recipient, the encryption process using both: 

- an encryption key formed using at least policy data indicative of conditions to be 
satisfied before access is given to said personal data; and 

- public data provided by a trusted party and derived thereby using private data; 
second operations, effected by the trusted party, comprising using the encryption key and 

15 said private data to determine a decryption key, and outputting this decryption key; at 
least one of these second operations only being effected after a further second operation 
has checked that said conditions are satisfied regarding said recipient. 

The conditions to be satisfied may relate to the authenticity of the recipient, the security 
0 rating of the computing platform used by the recipient, a "use-before" date for the policy or 
data, etc; a condition may also be that the trusted party communicate with the owner of the 
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personal data either by way of a simp.e notification or to ge, permission to deliver the 
decryption key. 

Th. trusted party preferably keeps an audi, record of each decryption key i, delivers and 
5 each failed request for a key. 

According to another aspect of the present invention, there is provided a privacy 
management system comprising first, second and third computing entities, wherein- 
- the firs, computing entity comprises: a data store holding personal data; an encryption 
urn, for encrypting the personal data using both an encryption key fonned using a, least 
poucy data indicative of conditions to be satisfied before access is given to said 
personal date, and public data provided by the second computing entity; and a 
communications interface for providing the encrypted data to toe thirt computing 
entity, 6 

15 - the second computing entity comprises a data store holding private data- a 
communications interface for receiving the encryption key and for providing a 
corresponding decryption key to the third computing entity; a decryption-key 
determmation unit for using the private data and fire received encryption key to 
determtne th. corresponding decryption key for dectypting the encrypted data; and a 
condttion-checking arrangement for ensuring tha, the decryption key is only 
detenmned, or only provided to the nurd computing entity, after the conditions in said 
pohcy data have been satisfied in respect of the third computing entity. 

A ~°^'°afurmeraspecto^^^ 

arranged to act as a trnsted party, the computing entity comprising: " 

- a data store holding private data; 

- a conizations interface for receiving an encryption key and for outputting a 
corresponding decryption key to a requesting entity; the encryption key being formed 
usxng at least policy data indicative of conditions to be satisfied before access is 

30 given to data encrypted with the key; 

- a decryption-key determination unit for using the private data and a received 
encryption key to determine a corresponding decryption key for decrypting data 
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encrypted using the encryption key and public data derived using said private data; 
and 

- a condition-checking arrangement for ensuring that the decryption key is only 
determined, or only output via the communications interface, upon the conditions in 
said policy data being satisfied in respect of the requesting entity. 

Brief Description of the Drawings 

Embodiments of the invention will now be described, by way of non-limiting example, 

with reference to the accompanying diagrammatic drawings, in which: 

. Figure 1 is a diagram illustrating the operation of a prior art encryption schema 

known as Identifier-Based Encryption; 
. Figure 2 is a diagram of an embodiment of the present invention; 
. Figure 3 shows an XML-format message comprising a privacy policy and data 

encrypted using the policy as the encryption key according to the IBE 

schema; and 
. Figure 4 is a diagram of a policy hierarchy. 

Best Mode of Carrying Out the Invention 

Figure 2 illustrates a privacy management system in which a data-owner computing entity 
20 is arranged to encrypt personal data and send it to a data-recipient computing entity 30 
which then requests a decryption key from a trust authority computing entity 40 and, on 
receipt of the key, decrypts and uses the personal data. The computing entities 20,30 and 
40 inter-communicate, for example, via the internet or other computer network though it is 
also possible that two or all three entities actually reside on the same computing platform. 

The system employs Identifier-Based Encryption with the computing entities 20, 30 and 40 
having the roles of the data provider 10, data recipient 1 1 and trusted authority 12 of the 
Figure 1 IBE arrangement. The IBE algorithm used is, for example, the QR algorithm 
described above with respect to Figure 1 . The encryption key used to encrypt the personal 
data is a privacy / disclosure policy setting out conditions that must be satisfied before 
access is given to the personal data. This policy and the related personal data is made 
available in any suitable manner (including by direct peer-to-peer communication, by e- 
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mail, orbypostingonapublicsite)tothedata recipient entity 30. In the Figure 2 example 
the pohcy and related personal data are depicted as being sent in a data package 25 directly 
to the datarecipient entity 30 (see arrow 50). On receipt, the entity 30 forwards thepolicy 
to the trust authority entity 40 with a request for a decryption key (see arrow 51). The trust 
5 authonty entity 40 is then responsible for ensuring that all the conditions of the pohcy have 
been met either before it generates the decryption key, or before it supplies the decryption 
key to the recipient entity 30 (see arrow 53). One possible condition involves the trust 
authonty entity 40 communicating with the owner entity 20 (see arrow 52) either simply to 
notify the latter or to obtain authorisation to proceed with the provision of the decryption 
1 0 key to the recipient entity 30. Advantageously, the trust authority entity keeps an auditable 
record of Us interactions with the recipient entity. The trust authority entity will typically 
serve multiple data recipient entities in respect of data from multiple data owner entities. 

Moreparticularly, the data-owner20 entity comprises a data store 21 for holding personal 
15 ^andrelatedd^^^ 

interacts with the recipient entity 30, and a communications module 24 for 
communicating with the other entities 30, 40. The browser 22 has a plug-in 23 that 
provides thelBEfunctionahty needed by the entity 20, this plug-in 22 being provided for 
example, by the trust authority entity 40. Where the QR ffiE method is being used the 
20 P^-thuscontams^^ 

for encryptmg data using N and an encryption key string formed by the disclosure policy 
relevant to the data concerned. 

Preferably, the personal data is divided into multiple components each with its own 
25 drsclosurepolicywherebydifferentconchtionscanbesetondifferen^ items of personal 
data. The data package 25 out by the entity 20 may include one or more personal-data 
components and their related policies. 
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With respect to the or each policy, such a policy can include conditions relating to: 
- the strength of cryptographic methods to be employed in authenticating the identity of 
recipient before the decryption key is provided to the latter. 
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- the expiry date of the policy or of the personal data, the trusted authority being 
arranged not to the decryption key when the expiry date has passed. 

- a security parameter of a computing platform being used by the recipient. 

- an action to be performed by the trust authority entity such as communicating with the 
5 owner, the trusted party effecting this communication before providing the decryption 

key to said recipient. 
Other types of condition are also possible. 

The policies can be expressed in any suitable language, for example XML. Figure 3 shows 
10 an example data package 25 in XML format for one data component (attribute 1); as can be 
seen the package comprises a policy section 26 and an encrypted data section 27 (the 
dashed lines simply being included to delimit these sections for the purpose of clarity). 
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The policy illustrated in the policy section 26 of the Figure 3 data package 25 comprises: 

• An encrypted "identifier" of owner (see "owner details" tag). This can be any 
information, including the owner's e-mail address, URL, etc. In this example, a 
"reference name" (a pseudonym, for example) has been used as an BE encryption 
key to encrypt this information. Only the competent trust authority entity 40 will 
be able to retrieve the owner's identifier (and use it, for example, to notify the 

20 owner of a disclosure or ask for an authorization). 

• The name of the attached confidential attribute (see "target" tag); 

• An expiration date for the policy or associated attribute data (see ""validity" tag): 
after this date the trust authority entity 40 is required not to issue the decryption 
key; 

25 • Policy conditions divided into constraints and actions: the constrains require the 
recipient entity 30 to strongly authenticate itself to the trust authority entity 40, 
and specify the usage of the attribute. The action condition requires the trust 
authority entity to notify the user of a disclosure. 



30 



Any kind of condition can be added, as long as the trust authority and the recipient entity 
can understand its semantic. The format adopted for the policy in its form included in the 
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data package 25 and its form used as the BE enaction key string need not be the same 
provided the forms used are known to the entities who have a need to know. 

Considering next the data recipient entity 30, this comprises a credentials database 3 1 an 
5 IBE decryption module 32, a policy engine 33 and a communications module for 
communicating with the entities 20 and 30. On receipt of the data package 25, the policy 
engme 33 programmatically interprets the associated disclosure policies in order to 
determine what information (including authentication credentials, business related 
information, company/individual policy related to data disclosure, usage and storage 
10 software state, platform configuration etc.) it will need to provide to the trust authority 
entity 40. The policy engine33is then responsible for sending to the entity 40, in respect of 
each encrypted personal-data component, a request for the decryption key, this request 
being accompaniedbytherelevant policy and the information which the engine believes is 
required from it to satisfy the conditions in the policy. 

15 

The receiving entity is thus explicitly aware of the conditions put on access to the 
encrypted data. 

Thetnist a umorityentity40compnsesadatastore41,adecryption 
20 42, a policy engine 43 (different in functionality to that of the entity 30), an audit data 
module 44, and a communications module 46 for communicating with entities 20 and 30 
On receiving a request for a decryption key from the entity 30, the policy engine 43 of the 
trust authority programmatically interprets the conditions in the associated policy and 
detennmeswhemermeinformationprovidedbythe entity 30 in therequest satisfies aU the 
25 conditions in the policy that are satisfiable by the entity 30. Tfre policy engine 43 may 
determine that the information given is inadequate and may send back a query to the entity 
for further information. Certain conditions in the policy may not rely on information from 
the entity 30 to be satisfied; one such condition is an action condition requiring the entity 
40 to notify the data-owner entity 20 or to seek its explicit authorisation for release of the 
3 0 decryption key concerned. 
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If and when the policy engine 43 is satisfied that all policy conditions have been met, it 
causes the key generation module 42 to generate the required decryption key from the 
policy (acting as the corresponding encryption key) and the private data (the value N in the 
case of the QR ffiE method) securely stored in store 41. The decryption key is then sent 
back to the entity 30. However, if one or more of the policy conditions is not satisfied, the 
entity 40 notifies the entity 30 accordingly and does not generate or output the requested 
decryption key. 

It will be appreciated that rather than the entity 30 providing the information required for 
satisfaction of policy conditions in the decryption-key request, this information can be 
requested by the entity 40 as required to satisfy each condition as it is inspected by the 
policy engine 43. Furthermore, the decryption key can be generated at the same time as, or 
even before, the policy conditions are checked; in this case, the decryption key is not, 
however, released until the conditions are all found to be satisfied. 

Whether or not a decryption-key request is successful, the audit data module 44 generates 
an audit record 47 comprising the identities of the entities 20 and 30, the personal-data 
component concerned and the information used to satisfy - or failing to satisfy - each 
policy condition. This audit record 47 is stored in store 41 to provide an audit trail 
regarding the disclosure of personal data and attempted accesses to it; this audit trail can be 
used latter as evidence for future contentions or forensic analysis. 

Thus, if the recipient entity 30 discloses data in a way that is not allowed by the policies, 
there is an audit trail at the trust authority entity 40 showing that the entity 30 knew about 
the policy. In case of identity or profile thefts, the audit information can be used to pin 
down a list of potential "offenders" and carry on forensic analysis. Enforcing the tracing 
and auditing of disclosures makes the information recipients more accountable. 
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The trust authority entity 40 is the most suitable place to implement tracing and auditing 
activities as data recipients 30 need to interact with the trust authority entity 40 to obtain an 
IBE decryption key. 



It should be noted that once personal data has been disc.osedtoarecipien.entitySOandi. 

.s.nclea I .ext(a,aereoipientsite),itcanpoten.iall y bemis„ S ed.However,theprovision 
of audi, mformation in described system facilitates the identification of the sonrce of any 
abuses. 

5 

Infteforegoingexa m pleofada,apackage25pvenwi«hrespecttoFigu re 3,onlyonedata 
cotnponent and one associated policy is shown. However, i, win be appreciated that the 

toapackagecancontainmnltipledatacompon^ each with its own associated policy in 

^^-ethen.stauftoriryenfity^isarrangedtoprovtdeacorrespondingnnrnberof 
decrypts keys each subject to the satisfaction of the conditions in tire corresponding 
pohcy. Of course, tire same policy can be applied to multiple items of the personal data 
Furthermore, i, is possible to provide a se, of policies where two or mo re policies can be 
used m combination to protect a particular , item of personal -data whilst different 
combmatton of policies can be used to protect a different item of personal data 

15 

Figure 4 depicts a set of policies organised as a nee-stntctured hierarchy with policy PI 

form 1 ngtheroot(nrs tl evel)nodetoapplytoalldata,pohciesP2.1,P2.2andP2 3 forming 
second-level nodes, and policies P3. lto P3.7 fonning third-level nodes. Dam itemstobe 
encrypted are associated with one or more of the nodes (as indicated by the rectangular 
20 boxes «D" and dashed hues in Figure 4). To encrypt any particular data item, either a 
"pohcy concatenation" or a >licy nesting" appmach is apphed, as explained below 
Pohcy Concatenation - with mis approach, all tire policies traversed from the mo, node 

to the node with which the data item concerned is associated, are 

ooncatenated(intheirorderoftraversalortherevetaeorder),'and 
* e coaMe ^^ P»Kcies are then used as the encryption key for 
encrypting the data item. 
Policy Nesting - wxth this approach, the policy of the node with which the data 

item concerned is associated, is used to encrypt the data item and 
^ the encrypted data item then becomes a data item associated with 

30 ^ parent node of Ae nod e Just used. In their turn the data items 

of the parent node are encrypted (either individually, or all 
together) using the corresponding policy to become one or more 
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data items for the node above, and so on. This approach requires 
encryption to be initiated from the bottom up (that is, starting at 
the leaf nodes) 

In both cases, each policy may specify any appropriate trust authority though, in the "policy 
5 concatenation" approach, if the policies being concatenated specify different trust 
authorities, one is selected to be used for the concatenation. 

In one example of a hierarchy of policies where "policy concatenation" is applied, the 
second-level policies are used as class policies that are to apply to respective different 

1 0 classes personal data items, and third-level policies are used as policies that are to apply to 
respective individual personal data items. In this case, items of personal data are only 
associated with the leaf (third-level) nodes so that every item of personal data is guarded by 
a combined policy made up of the concatenation of the root policy, the appropriate class 
(second level) policy and the appropriate individual (third level) policy; the combined 

1 5 policy forms the encryption key for the data item and is used by the trust authority to derive 
the corresponding decryption key (after all the relevant policy conditions are satisfied). 
With this particular example in which data items are only associated with leaf nodes, it is 
still possible to dispense with the application of policy conditions at any one or more levels 
simply by arranging for one or more policies to be empty. 

20 

It will be appreciated that whilst it is preferable for the lower level policies to be consistent 
with the higher level ones, this is not essential as rules can be applied by the trust authority 
entity to resolve any policy conflicts - for example, a higher level policy can be arranged to 
overrule lower level policies (or vice versa), or a more specific policy condition can be 
25 arranged to overrule a more general one. 

Although in Figure 4, each data item "D" is shown as associated with a single node, it 
would also be possible to associate a data item with multiple nodes; this would be 
advantageous where different branches of the policy hierarchy related to different policy 
30 topics and it was desired to apply multiple topics to a data item. In this case, combining the 
policies encountered in traversing the hierarchy from its root to each node associated with a 
subject data item can be. done in a number of different ways. For example, a "policy 
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concatenation" approach can bo applied to all such policies, possibly with the elimination 
of repeated policies (nodes traversed tore than once). Another approach is to use "policy 
concatenation" for each traversal and theu use each concatenated policy set to encryp, the 
data .ten, m tun, Yet another approach would be to use "policy nesting" with each level in 
5 the herarchy being taken in turn (from the bottom up) and the concerned policies a. the 
same level each being used in turn for enaction. 

To enable a multiparty transaction, the recipient entity 30 can be authorised (for example 
» a pohcy condition) to pass the overall encrypted data or any encrypted component of ft 
1 0 to a further party (or parties) who then must contact fhe tins, authority for the dectyption 
key, agatn the decryption key is onlyprovided ifthe relevantpolicyconditionsare satisfied 
m respect of tins farther party In passing on the received personal data, the recipient entity 
30 may decide to further encrypt portions of this data by nsing additional policies and in 
tins case the module 32 would be arranged to carry on, both decryption and encryption 
15 °P™»°™ ™s former encryption p^^ 

decrypted personal date items fiom entity 20, or to the date items whilst still in their fomr 
as encrypted by fhe entity 20 (in which case, the pohcy or policies applied by the data- 
otvner entity 20 can conveniently encompassed within the data encrypted by the recipient 
entity 30). Impolicies applied by the entity 30 are of ite own choosing and, of course may 
20 spectfy a different trust authority to that specified by the entity 20. A further entity 
recetvmgthe encrypted datefiom the entity SOrnnst use the tins, authority specified by the 
entity 30 to obtain the decryption key( S ) for unlocking the encryption applied by the entity 
30; rftins unlocked date comprises date encrypted by entity20 and tire relevant policy, then 
the further entity must now use the tins, authority specified by the entity 20 to obtain the 
25 decryption key( s ) to finally gain access to the personal date provided by entity 20. 

As indicated in the foregoing discussions of the use of policies in combination and the 
passmg on of personal date by the recipient entity 30 to another party, multiple txust 
anthonties may need to be involved in providing access to the transmitted pentonal date Of 
30 most interest is the situation where the provider of a particular item of personal date 
encrypts that data item in such a way that multiple trust authorities need to be involved to 
enable a recetving party to access the date item. One reason for doing this is tha, different 
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trust authorities may have different competencies; for example, one trust authority may be 
competent to check platform security whilst another might be competent in the field of 
privacy. One way of requiring the involvement of multiple trust authorities is to use the 
"policy nesting" approach described above. However, it is also possible for the data 
5 provider to encrypt the data item using a key based on public data from each of multiple 
trust authorities (such public data being derived from private data of each trust authority), 
decryption of the encrypted item only being possible by obtaining a corresponding sub-key 
from each trust authority involved. Further information about how multiple trust 
authorities can be used is given in: 
10 L. Chen, K. Harrison, A. Moss, D. Soldera, N. P. Smart, "Certification of Public Keys 
within an Identity Based System", LNCS 2433, ed. G. Goos, J. Hartmanis and J. van 
Leeuwen, Proceedings of Information Security, pp. 332-333, 2002. 

Advantageously, one or more of the conditions of a policy require that the recipient entity 
15 30 is a misted platform with trusted integrity-checking mechanisms 35 that the trust 
authority entity 40 is to utilize to check that the software state of this platform is 
conformant with the disclosure policies, and that the platform correctly implements defined 
privacy management mechanisms. Suitable trusted mechanisms are described in: 

TCPA - Trusted Computing Platform Alliance Main Specification vl.l, 
20 www.trustedcomputing.org . 200 1 . 

The presence of trusted integrity-checking mechanisms 35 in the recipient entity 30 also 
permits the latter to be checked out by the data owner before any personal data is sent; such 
a check may be an alternative to, or additional to, the trust authority checking the recipient 
entity (it may be desirable for checking to be done both by the data owner and the trust 
25 authority since the state of the recipient entity may change between when the encrypted 
personal data is sent to the recipient and when it decides to access the data). 

Preferably, one or both the computing entities 20 and 40 are also trusted platforms with 
TCPA integrity-checking mechanisms 25 and 45 respectively. In this case, one or more of 
30 the following further checks can be carried out: 

- the trust authority's computing platform to be checked out by the data owner to ensure 
that the trust authority will operate as expected; 
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- the trust authority's computing platform to be checked out by the recipient of the data 
to help the recipient decide whether the trust authority can be trusted with the 
information that the recipient needs to provide in order for the decryption key to be 
issued; 

- where the data-owner's personal data is forwarded by the recipient entity 30 to another 
computing entity, then that further entity can check out the tmst authority and 
assuming that the further entity is itself provided win, trusted integrity-monitoring 
mechanisms, the further entity can be checked ou, by the tins, authority and the 
recipient entity 30; 

- thedata °wner's 
recipient entity. 



The mtegrity-chccking mechanisms 35 provided at the recipient entity 30 (or at any other 
subsequent recipient of the personal data of data-owner 20) can be used to effectively 
15 - fo -properhandlm g ofmepersonaldataitreceives,byre q u^^ 

of the entaty 30 corresponds to the use of software that can be trusted to operate m a 
predetermmed manner (for example, a Trusted Operating Systems (OS s) or software with 
known behaviour that is being run in the absence of subversive software). Thus where a 
Trusted OS can be arranged not to pass on data tagged in a certain manner to another 
20 entity, the data-owner entity can ensure that a particular data kern is not disclosed beyond 
the recmxent entity by tagging the data item in the appropriate manner and setting a policy 
condmon to be checked by the trust aumority, mat the recipient entity must be rnnning the 
Trusted OS before the decryption key is generated/ provided to the entity 30. 

25 ^rmanmetrustaumoritybemgseparatefromm^ 

entaty 20 can be arranged to run trust authority services itself in order to have first hand 
understanding of what happens to its information and make ultimate decisions about 
release of decryption keys. In this case, the personal-data owners can directly use a TCPA 
mtegnty challenge to check that the computing platform of the recipient has not been 
30 corrupted, before proceeding with the data disclosure. (It may be noted that where the 
owner ennty and trust authority entity are combmed, the so-called "public" data of the trust 
authonty may not, in practice, be published outside of the combined entity; however the 
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term "private" is still apt to distinguish the data concerned from the private data of the trust 
authority). 



5 It will be appreciated that many other variants are possible to the above described 
embodiments of the invention. For example, the recipient entity 30 may choose to cache a 
received decryption key to decrypt the data package 25 at a later date. Furthermore, in 
order to prevent the use of a decryption key in respect of more than one output of personal 
data by the entity 20, a nonce, i.e. a random number, can be incorporated into the policy at 
1 0 each transmission. This ensures that the encryption key is unique thereby ensuring that the 
corresponding decryption key will also be unique. 

Rather than the trust authority supplying the decryption key directly to the data recipient 
entity directly, the trust authority could send the key to the data-owner entity for 
1 5 forwarding to the data recipient entity. 



Since in the Figure 2 embodiment of the trust authority 40, an audit record is kept of the 
owner 20 and recipient 30 of a particular data item for which the recipient entity 30 has 
been provided the decryption key, if the trust authority 40 subsequently receives a request 
from a further entity for the decryption key for the same data item, the trust authority 40 
can check whether the implied onward transmission of the data by the entity 30 may have 
breached a condition of the policy associated with the data item. For simplicity, the trust 
authority may assume that the data item had the same associated privacy policy when 
handled by the recipient 30 as when handled by the subsequently-requesting entity; in this 
case, the trust authority need only check the policy conditions in the later request to see if 
the recipient entity 30 had the right to pass on the data item. However, it is also possible 
for the trust authority 40 to record the policy under which the decryption key was released 
to the entity 30 and, in this case, the trust authority can checked the recorded policy for a 
condition preventing onward transmission. If a breach is indicated, then the trust authority 
40 is preferably arranged not to release the decryption key and to log the event (it may also 
immediately notify the data owner). Of course, even if the data item was disclosed to the 
recipient entity 30 under a policy forbidding onward disclosure, it is possible for the later- 



requesting entityto have leghtaa.dyreceived.hedataitem as toe data item mayhave been 
prided 'o«hela«er- req n« tfagmtity byadiffere n .pa rty ( S ucha sai e data owner) having 
•be ngh t ,o do so; care toerefore needs ,o be taken as to bow the tats, authority carries on, 
me pobcy compliance check jus, described. In fac inappropriate refusal to snpply a 
decryption key can be targeiy avoided by having the party making the request for the 
demyptmn key, indicate from whom it received the data item; this additional information 
enab.es the trust authority to deternrinewhatpohcy was appiicable to the party passing on 
the data item to the Resting party. An alternative won.d be ,o umqnely number each 

-^o^P-'-ybymedataownerfforexam^cbyindudrngausageseriamnmberora 
10 none in the policy) so that where a request is made for a decryption ■ key «ha, is 
accompanied by the pohcy used as the encryption key, i, is simple matter for the bust 
authority to check its audi, records for any previous request regarding me same policy 
usage and thus detertnine any breaches of a non-disclosure condition of me policy. 

15 ^'^foegomgembodiment,^ 

hasbeenuseddirecayinmeQRrBEalgorimmfma.is.as.he.enc^.ionkey.Jasse.on, 
» me mhoducoo, portion of me specification, i, is also possible ,o use a derivative of me 
enctyption key string as me encr^tion key as explained in the introductoty portion- in tins 

^^^fenkeysti^ramermanoraswellasmeencryptionkey.fapassed.oti.e 
20 bus, authonty 40 so ma, me contents of me encryption key string are visible ,o the « 
authority. 

I, wi), be appreciated ma, instead of me QR ffiE method, me above-described 
embodunents cat, be implemented using other, analogous, cryptographic methods such as 
& IBE methods based on Weil or Tate pairings. 

The above-described privacy management system can be used in any area of application 
mcludmg e-commerce, financial, government and enterprise areas. 
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CLAIMS 

1. A privacy management method, comprising: 

first operations, effected by an owner of personal data, comprising encrypting the personal 
data and providing the encrypted data to a recipient, the encryption process using both: 

- an encryption key formed using at least policy data indicative of conditions to be 
satisfied before access is given to said personal data; and 

- public data provided by a trusted party and derived thereby using private data; 
second operations, effected by the trusted party, comprising using the encryption key and 

said private data to determine a decryption key, and outputting this decryption key; at 
least one of these second operations only being effected after a further second operation 
has checked that said conditions are satisfied regarding said recipient. 

2. A method according to claim 1, wherein the first operations further comprise providing 
the encryption key to said recipient along with the encrypted data; the method further 
comprising intermediate operations in which the recipient provides the trusted party with 
the encryption key and requests the decryption key. 

3. A method according to claim 1 or claim 2, wherein the first operations further comprise 
providing details of the trusted party to said recipient along with the encrypted data. 

4. A method according to any one of claims 1 to 3, further comprising said recipient 
sending on the encrypted personal data to a further party, and the trusted party providing 
the decryption key to that further party only after said conditions have been satisfied in 
respect of that further party. 

5. A method according to claim 1, wherein in said first operations multiple items of 
personal data are encrypted each using said public data and a respective encryption key 
formed using at least respective policy data; the encrypted multiple items being provided to 
said recipient; and wherein in the second operations the trusted party determines the 
decryption key for at least one encrypted item using the corresponding encryption key and 
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said private data, the or each determined decryption key only being provided to said 
recipient after the conditions in the corresponding policy data have been satisfied. 

6. A method according to claim 5, further comprising said recipient sending on a selected 
5 subset of said multiple encrypted items of personal data to a further party; and the trusted 
party providing to that further party a decryption key for an encrypted item provided to that 
party, only after the conditions in the corresponding policy data have been satisfied in 
respect of said further party. 

10 7. A method according to claim 1, wherein the data owner has a set of policies that form 
respective nodes in a policy hierarchy, and wherein in said first operations, multiple items 
of personal data are encrypted and provided to said recipient, each such data item being 
independently associated with at least one node of the policy hierarchy and being encrypted 
using said public data and policy data formed by a concatenation of the policies of the 

1 5 nodes traversed between the root of the hierarchy and the said at least one node with which 
the data item is associated. 

8. A method according to claim 1, wherein the data owner has a set of policies that form 
respective nodes in a policy hierarchy, and wherein in said first operations, multiple items 
20 of personal data are encrypted and provided to said recipient, each such data item being 
independently associated with at least one node of the policy hierarchy and being encrypted 
by an iterative process in which: 

- the data item is encrypted using said public data and policy data formed by the policy 
of the said at least one associated node, 

- the encrypted data thus produced then becoming a data item associated with the parent 
node of the or each node formed by the policy just used for encryption. 
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9. 



A method according to claim 1, wherein in said first operations, multiple items of 
personal data are encrypted and provided to said recipient, at least two of these data items 
30 being encrypted using public data of different respective trusted parties whereby the 
recipient must obtain the appropriate decryption key from a different one of the trusted 
parties in dependence on which data item the recipient wishes to access. 
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10. A method according to claim 1, wherein in said first operations an item of personal 
data is first encrypted using a first policy and the public data of a first trusted party with the 
encrypted data being then further encrypted using a second policy and the public data of a 

5 second trusted party whereby the recipient must obtain decryption keys from the two 
trusted parties in order to access the data item. 

11. A method according to claim 1, wherein in said first operations the personal data is 
encrypted using public data provided by multiple trusted parties, the second operations 

1 0 being carried out by each of said multiple trusted parties to provide a respective decryption 
sub-key whereby to enable the recipient to decrypt the encrypted personal data by the 
combined use of the sub-keys from each trust authority; each trusted party ensuring that 
. policy conditions for which it is competent have been satisfied before generating and/or 
outputting the corresponding sub-key. 

15 

12. A method according to claim 1, wherein the trusted party makes an audit record of 
each provision of a decryption key by the trusted party. 

13. A method according to claim 12, wherein said audit record further comprises 
20 information about when a decryption key is not provided because a related policy condition 

has not been satisfied, this information including information about the condition failure. 

14. A method according to claim 12, wherein the trusted party on receiving a request from 
a party for a decryption key in respect of a particular item of data, checks its audit records 

25 to ascertain whether the decryption key for that item has previously been provided to a 
different party, and if so, whether the policy associated with the data item permitted 
onward disclosure. 

15. A method according to claim 14, wherein the trusted party, on determining that the 
30 decryption key for the data item was previously provided under a policy of no onward 

disclosure, refuses to provide the decryption key to the requesting party. 
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16. A method according to claim 1, wherein the first and second operations are repeated 
multiple times for the same or different personal data owned by the same or different 
personal-data owners and provided to the same or different recipients. 

5 17. A method according to claim 16, wherein the trusted party makes an audit record of 
each provision of a decryption key by the trusted party. 

18. A method according to claim 17, wherein said audit record comprises the identity of 
the personal data, personal-data owner and recipient concerned. 
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19. A method according to claim 17 or claim 18, wherein said audit record further 
comprises information about when a decryption key is not provided because a related 
policy condition has not been satisfied, this information including information aboutthe 
condition failure. 
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20. A method according to claim 17, wherein the trusted party on receiving arequest from 
a party for a decryption key in respect of a particular item of data, checks its audit records 
to ascertain whether the decryption key for that item has previously been provided to a 
different party, and if so, whether the policy associated with the data item permitted 

20 onward disclosure. 

21. A method according to claim 20, wherein the trusted party, on determining that the 
decryption key for the data item was previously provided under a policy of no onward 
disclosure, refuses to provide the decryption key to the requesting party. 

25 

22. A method according to claim 1, wherein a said policy condition relates to the strength 
of cryptographic methods to be employed in authenticating the identity of the recipient 
before the decryption key is provided to the latter. 

30 23. A method according to claim 1, wherein a said policy condition relates to the expiry 
date of the policy or of the personal data, the trusted party not providing the decryption key 
when the expiry date has passed. 
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24. A method according to claim 1, wherein a said policy condition relates to the trusted 
party communicating with the owner, the trusted party effecting this communication before 
providing the decryption key to said recipient. 

5 

25. A method according to claim 24, wherein the condition is that the trusted party obtain 
consent from the owner before providing the decryption key to said recipient. 

26. A method according to claim 24, wherein contact details for the owner are contained in 
1 0 policy data in encrypted form, the contact details being encrypted using said public data of 

the trusted party and an encryption key formed by a data element also included in the 
policy data whereby the trusted party can form the corresponding decryption key and 
decrypt the encrypted contact details. 

15 27. A method according to claim 1 , wherein a said policy condition relates to a computing 
platform being used by the recipient being a trusted platform running software of 
predetermined functionality that cannot be subverted. 

28. A method according to claim 1, wherein the trusted party checks that any party 
20 requesting the decryption key is using a trusted computing platform running software of 

predetermined functionality that cannot be subverted. 

29. A method according to claim 1, wherein the data owner, before providing the 
encrypted data to the recipient, checks that the latter is using a trusted computing platform 

25 running software of predetermined functionality that cannot be subverted. 

30. A method according to any one of claims 27 to 29, wherein the software being run by 
the computing entity of the recipient is arranged to prevent onward disclosure of data 
indicated in a predetermined manner, the data owner marking an item of personal data in 

30 this predetermined way before providing it to the recipient. 
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31. A method according to claim 1, wherein the data owner, before providing the 
encrypted data to the recipient, checks that the trust authority is using a trusted computing 
platform running software of predetermined functionality that cannot be subverted. 

5 32. A method according to claim 1, wherein the recipient, before providing the trust 
authority with any data concerning itself for the purpose of satisfying a said condition, 
checks that the trusted party is using a trusted computing platform running software of 
predetermined functionality that cannot be subverted. 

10 33. A method according to claim 1 , wherein the recipient, before providing any personal 
data received from the data owner to another party, checks that the latter is using a trusted 
computing platform running software of predetermined functionality that cannot be 
subverted. 

15 34. A method according to claim 1 , wherein the owner of the personal data also serves as 
the trusted party. 

35. A method according to claim 1 , wherein said owner is acting as a proxy for a party to 
whom the personal data relates. 

20 

36. A method according to claim 1 , wherein in the second operations the decryption key is 
not determined until after said conditions have been satisfied. 

37. A privacy management system comprising first, second and third computing entities, 
25 wherein: 

- the first computing entity comprises: a data store holding personal data; an encryption 
unit for encrypting the personal data using both an encryption key formed using at least 
policy data indicative of conditions to be satisfied before access is given to said 
personal data, and public data provided by the second computing entity; and a 
30 communications interface for providing the encrypted data to the third computing 
entity; 
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- the second computing entity comprises a data store holding private data; a 
communications interface for receiving the encryption key and for providing a 
corresponding decryption key to the third computing entity; a decryption-key 
determination unit for using the private data and the received encryption key to 
5 determine the corresponding decryption key for decrypting the encrypted data; and a 
condition-checking arrangement for ensuring that the decryption key is only 
determined, or only provided to the third computing entity, after the conditions in said 
policy data have been satisfied in respect of the third computing entity. 

10 38. A system according to claim 37, wherein the first computing entity is arranged to 
provide the encryption key to the third computing entity along with the encrypted data; the 
third computing entity being arranged to request the decryption key from the second 
computing entity and provide it with the encryption key. 

15 39. A system according to claim 37, further comprising a fourth computing entity, the 
third computing entity being arranged to send on the encrypted personal data to the fourth 
computing entity, and the second computing entity being arranged to provide the 
decryption key to the fourth computing entity only after said conditions have been satisfied 
in respect of that fourth computing entity. 

20 

40. A system according to claim 37, wherein the second computing entity is arranged to 
make an audit record of each provision of the decryption key by the second computing 
entity. 

25 41. A system according to claim 40, wherein the second computing entity is arranged to 
include in the audit record, information about when a decryption key is not provided 
because a related policy condition has not been satisfied, this information including 
information about the condition failure. 

30 42. A system according to claim 40, wherein the second computing entity is so arranged 
that upon receiving a request from a party for a decryption key in respect of a particular 
item of data, it checks its audit records to ascertain whether the decryption key for that item 
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has previously been provided to a different party, and if so, whether the policy associated 
with the data item permitted onward disclosure. 

43. A system according to claim 37, Anther comprising multiple first and third computing 
entities, the second computing entity being arranged to provide decryption keys for the 
third computing entities in respect of personal data encrypted by the first computing 
entities provided the corresponding policy conditions have been satisfied in each case. 

44. A system according to claim 37, wherein the second computing entity is arranged to 
make an audit record of each provision of a decryption key by the second computing entity. 

45. A system according to claim 44, wherein said audit record comprises the identity of 
the first and third computing entities concerned with each provision of a decryption key. 

46. A system according to claim 44 or claim 45, wherein the second computing entity is 
arranged to include in the audit record, information about when a decryption key is not 
provided because a related policy condition has not been satisfied, this information 
including information about the condition failure. 

47. A system according to claim 44, wherein the second computing entity is so arranged 
that upon receiving a request from a party for a decryption key in respect of a particular 
item of data, it checks its audit records to ascertain whether the decryption key for that item 
has previously been provided to a different party, and if so, whether the policy associated 
with the data item permitted onward disclosure. 

48. A system according to claim 37, wherein a said policy condition relates to the second 
computing entity communicating with the first computing, the second computing entity 
being arranged to effect this communication before providing the decryption key to said 
third computing entity. 
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49. A system according to claim 48, wherein the condition is that the second computing 
entity obtain consent from the first computing entity before providing the decryption key to 
the third computing entity. 

5 50. A system according to claim 48, wherein contact details of the first computing entity 
are included in said policy data in encrypted form, the contact details being encrypted using 
said public data and an encryption key formed by a data element also included in the 
policy data whereby the second computing entity can form the corresponding decryption 
key and decrypt the encrypted contact details. 

51. A system according to claim 37, wherein a said policy condition relates to the third 
computing entity being a trusted platform running software of predetermined functionality 
that cannot be subverted. 

15 52. A system according to claim 37, wherein the first and second computing entities are 
combined. 

53. A computing entity arranged to act as a trusted party, the computing entity comprising: 
a data store holding private data; 
20 - a communications interface for receiving an encryption key and for outputting a 
corresponding decryption key to a requesting entity; the encryption key being formed 
using at least policy data indicative of conditions to be satisfied before access is 
given to data encrypted with the key; 

- a decryption-key determination unit for using the private data and a received 
25 encryption key to determine a corresponding decryption key for decrypting data 

encrypted using the encryption key and public data derived using said private data; 
and 

- a condition-checking arrangement for ensuring that the decryption key is only 
determined, or only output via the communications interface, upon the conditions in 

30 said policy data being satisfied in respect of the requesting entity. 



30 

54. A computing entity according to claim 53, further comprising an audit-trail 
arrangement for making an audit record of each output of a decryption key to a requesting 
entity. 

5 55. A computing entity according to claim 54, wherein the audit-trail arrangement is 
arranged to include in the audit record information about when a decryption key is not 
provided because a related policy condition has not been satisfied, this information 
including information about the condition failure. 
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56. A computing entity according to claim 54, in which the audit-trail arrangement is 
arranged, in response to the computing entity receiving a request from a party for a 
decryption key in respect of a particular item of data, to checks its audit records to ascertain 
whether the decryption key for that item has previously been provided to a different party, 
and if so, whether the policy associated with the data item permitted onward disclosure. 

57. A computing entity according to claim 56, wherein the audit-trail arrangement is 
further arranged, on determining that the decryption key for the data item was previously 
provided under a policy of no onward disclosure, to block the generation and/or output of 
the decryption key. 

58. A computing entity according to claim 53, wherein a said policy condition relates to 
the computing entity communicating with an owner of the encrypted data, the computing 
entity being arranged to effect this communication before generating and/or outputting the 
decryption key to the requesting entity. 

59. A computing entity according to claim 58, wherein the condition is that the computing 
entity obtain consent from the owner of the encrypted data before providing the decryption 
key to the requesting entity. 

30 60. A computing entity according to claim 53, wherein a said policy condition relates to 
the requesting entity being a trusted platform running software of predetermined 
functionality that cannot be subverted, the computing entity being arranged to 
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communicate with the requesting entity to check this condition before generating and/or 
outputting the decryption key. 
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ABSTRACT 
Privacy Management of Personal Data 

5 

When sending personal data to a recipient (30), the data owner (20) encrypts the data using 
both a public data item provided by a trusted party (40) and an encryption key formed 
using at least policy data indicative of conditions to be satisfied before access is given to 
the personal data. The encryption key is typically also provided to the recipient (30) along 

1 0 with the encrypted personal data. To decrypt the personal data, the recipient (3 0) sends the 
encryption key to the trusted party (40) with a request for the decryption key. The trusted 
party (40) determines the required decryption key using the encryption key and private data 
used in deriving its public data, and provides it to the requesting recipient (30). However, 
the decryption key is either not determined or not made available until the trusted party 

15 (40) is satisfied that the associated policy conditions have been met in respect of the 
recipient. One possible policy condition is that the trusted party (40) must first get 
confirmation from the owner (20) of the personal data before providing the decryption key. 
Preferably, the trusted party (40) keeps a record (47) of the provision of decryption keys 

20 

(Figure 2) 
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<data package> 

<data component> 
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// profile - attribute 1 & related policy 



<policy> 



//DISCLOSURE POLICY 



<Trusted Authority> 

address and location of the Trusted Authority 
<ATrusted Authority> 



//TA 



<owner> 

<reference name> 

. pseudonym! 
Preference name> 
<owner's details> 

encrypted call back address 
<owner*s details> 
</owner> 

<target> 

name of the identity or profile attribute 
</target> 

<validity> 

expiration date 
</validity> 

<constraint> 

require_strong_X.509_authentication 
</constraint> 
<constraint> 

aUow_usage_of_data_# 1 
</constraint> 

<action> 

notify_owner 
</action> 
</policy> 



//owner 

//reference name - IBE public key 



//encrypted call back address 

//by using the user's reference name 
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//policy/attribute name 
//validity 

//constraints 



//actions 



<encrypted data> //ENCRYPTED DATA (Attribute 1) 

encrypted attribute 1 value, using the above policy as IBE public key 
</encrypted data> 
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</data component> 
</data package> 



Figure 3 
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Figure 4 
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